AI Agent 应用开发与 Python 后端开发学习复盘

引言： 这段时间的学习主要围绕两个方向展开：一是 AI Agent 应用开发，二是 Python 后端开发。前者让我理解大模型能力如何从简单问答走向任务规划和工具调用，后者让我理解一个 AI 应用如何被封装成稳定、可访问、可维护的真实服务。

在学习 Agent 的过程中，我也逐渐意识到，Agent 的优势在于它具备更强的主动性，能够根据目标进行规划、调用工具并执行任务。但与此同时，Agent 的主动性越强，使用者自身的控制感和参与感也可能被削弱，所以在设计 Agent 应用时，需要有清晰的能力边界和安全边界。

Agent 走向大众视野，意味着人工智能不再只是一个被动问答工具，而是开始成为可以参与任务规划、信息处理和实际执行的生产力工具。或许真的意味着人工智能从触碰到普通人的生活边界，开始转向成为水和电那样真正日常不可或缺的资源。

AI Agent

1. LLM、RAG、Agent 的关系

刚开始接触到agent这个概念，构建起对 LLM / Agent 的认知：

• 先理解了 LLM 的基本工作方式
  • 是基于已有训练结果和当前上下文，持续预测最可能出现的内容。
• 大模型应用不只是简单聊天，有Embedding、Copilot、Agent 三种交互形态。
• Agent 是把模型、工具和任务流程组织起来完成目标的应用形态。
  • LLM 是大脑，是构建起复杂AI系统的基础
  • RAG 是外部知识增强，从外部知识库中检索相关内容，再交给 LLM 生成更可靠的回答
  • Agent基于 LLM 和工具，感知环境、规划任务、执行动作

从 AI 到 Agent / Agentic 的变化，本质上是从“模型被动响应”走向“系统主动规划和执行”。

2. 从 AI Workflow 到 AI Agent

第一阶段 大语言模型（LLM）

• 基于LLM的训练数据，但受限于对专业知识了解有限
• passive，等待输入，然后响应 现在流行的这些主流聊天机器人就是基于LLM产出回应的

第二阶段 ai workflows ai需要遵行的固定的流程，预先被设定好的workflow

• 这里可以提供给LLM遵行的skills或者说限制prompt
• 也可能涉及从外部调用工具
• 人为设定LLM的工作路径， 纠错和调整的过程需要人来负责完成

第三阶段AI Agents 思考和推理 由人转向被LLM替代，这也是从普通的workflow转向agent的关键所在。 这里不得不引入一种构建agent的模式：

• ReAct Reasoning and Act

普通大模型本身无法感知外部环境，也不能直接改变外部状态；而 Agent 的核心区别在于，它可以通过工具读取外部信息、执行动作，并根据结果继续调整下一步。

3. Prompt 与 Agent 行为控制

关于提示题prompt包含：

• 系统提示词
  • 系统提示词一般会包含对于模型角色的设定，期望的回答，包括格式、涵盖的内容方面以及一些事例等等。好的系统提示词可以大大提升agent的质量。
  • 一般在做系统的时候会放进skills里面。
• 用户提示词（也就是用户的问题） 然后一起打包发送给LLM

二、LangChain / LangGraph：Agent 工程化框架

在建立了对 LLM、RAG、Agent 的基础认知之后，我开始进一步理解：如果要真正开发一个 Agent 应用，不能只停留在“调用一次大模型 API”的层面，需要一个框架来组织模型、提示词、工具、上下文、检索和执行流程。

LangChain 和 LangGraph 就是在这个阶段接触到的两个重要框架。有效的把 Agent 从一个概念，逐步理解成一个可以工程化实现的系统。

1. 为什么需要 LangChain

最开始调用大模型时，流程通常很简单：

用户输入 → 调用模型 → 返回结果

这种方式适合简单问答，但当应用变复杂后，就会遇到很多问题：

• 提示词越来越多
• 模型调用逻辑越来越复杂
• 需要接入外部工具
• 需要保存多轮对话上下文
• 需要从知识库或代码库中检索资料
• 需要控制模型输出格式
• 需要把多个步骤组合成一个完整流程

如果把这些功能的实现逻辑全部堆砌，和核心的业务逻辑混合，后续的维护和修改难度会很大。

所以我对 LangChain 的理解是：

LangChain 的作用，是把大模型应用中常见的能力抽象成可组合的模块，让开发者可以更方便地组织模型、Prompt、工具、记忆、检索和输出解析。

它解决的是“如何把模型能力高效接入真实应用”的问题。

2. LangChain 的核心组件

Agent 应用拆成几个核心组成。

首先是模型。模型是 Agent 的基础能力来源，负责理解用户问题、生成回答、判断下一步操作。

其次是 Prompt。Prompt 用来控制模型的行为，包括系统提示词和用户提示词。系统提示词一般用于设定模型角色、任务边界、回答格式和行为规则；用户提示词就是用户当前提出的问题。

然后是工具。工具让 Agent 具备和外部世界交互的能力。普通大模型只能根据上下文生成回答，而接入工具之后，Agent 可以读取文件、搜索代码、查询数据库、调用 API，甚至分析报错。

接着是 Agent。Agent 可以理解为模型和工具结合后的执行系统。模型负责理解和判断，工具负责执行具体动作，Agent 负责把两者组织成一个完整的任务流程。

还有记忆。记忆用于支持多轮对话，让 Agent 能够记住前面的上下文，而不是每次都像重新开始。

最后是 RAG，也就是检索增强生成。RAG 可以让模型先从外部知识库、文档或代码库中检索相关内容，再基于检索结果生成回答。 对于 RepoMind 这样的项目来说，这一点非常重要，因为它需要基于真实代码文件回答用户的问题。

3. Tool Calling 与 Agent 执行流程

Tool Calling 是 Agent 能够真正“做事”的关键。

普通大模型的流程通常是：

用户提问 → 模型生成回答

而 Agent 的流程是：

用户提出目标  
↓  
模型理解任务  
↓  
判断是否需要工具  
↓  
选择合适的工具  
↓  
调用工具  
↓  
观察工具返回结果  
↓  
继续推理  
↓  
生成最终回答

这里的核心变化是：模型不再只是一次性回答，而是可以进入一个“思考、行动、观察、再思考”的循环。

这也对应着 ReAct 的思想： Reasoning + Act

以 RepoMind 为例，如果用户问“这个项目的登录逻辑在哪里”，Agent 不应该直接凭空回答，而应该先搜索相关代码，再读取对应文件，最后结合真实代码位置给出回答。

所以我对 Tool Calling 的理解是：

Tool Calling 让 Agent 从“语言生成系统”变成了“任务执行系统”。

它把大模型的理解能力，连接到了外部工具、代码文件、数据库、API 和运行环境上。

4. LangGraph 的作用：把 Agent 流程变成可控状态图

在理解 LangChain 之后，我进一步认识到：当 Agent 流程变复杂时，只靠工具调用还不够，还需要一种更清晰的方式来管理整个执行过程。

真实的 Agent 应用往往不是一条简单直线，而是会出现多个步骤、条件分支、循环执行、人工确认、报错重试等情况。

这时候 LangGraph 的作用就体现出来了。

LangGraph 是用“状态图”的方式来组织 Agent 流程，让 Agent 的执行过程更清晰、更可控。

把一个复杂任务拆成：

• State：当前任务状态
• Node：每一步要执行的动作
• Edge：步骤之间如何流转

比如 RepoMind 的流程可以理解成：

接收 GitHub URL  
↓  
克隆仓库  
↓  
扫描目录  
↓  
读取关键文件  
↓  
分析技术栈  
↓  
生成项目理解报告  
↓  
根据用户问题检索代码  
↓  
生成回答或二次开发方案

如果进入二次开发阶段，还可以继续扩展成：

分析修改需求  
↓  
检索相关文件  
↓  
判断影响范围  
↓  
生成修改计划  
↓  
等待用户确认  
↓  
应用修改  
↓  
运行测试  
↓  
读取报错并继续 Debug

所以，LangChain 的功能是提供 Agent 需要的基础能力组件，比如模型、Prompt、工具、记忆和检索；而 LangGraph 更像是组装这些组件，来控制 Agent 的执行流程，让整个过程更稳定、清晰，更容易维护。

三、Python 后端开发基础

在学习 Agent 应用开发的同时，我也开始补 Python 后端基础。因为一个真正可用的 Agent 项目，不能只是模型调用，还需要后端来承接用户请求、管理接口、处理数据、连接数据库、统一错误返回，并保证系统可以被测试和维护。

对我来说，后端部分的学习价值在于：它让我开始理解一个 AI 应用从“模型能力”变成“真实产品服务”中间需要哪些工程支撑。

1. Flask / FastAPI 与接口开发

最开始接触后端时，我先理解了 Flask 这样的 Web 框架的作用。

Flask 可以让 Python 程序对外提供接口服务。也就是说，用户或前端访问某个 URL，后端就执行对应的 Python 函数，并返回结果。

一个基础流程可以理解为：

用户请求  
↓  
进入后端接口  
↓  
执行业务逻辑  
↓  
返回 JSON 响应

在学习阶段，我主要通过 Flask 理解后端接口的基本概念，比如路由、请求方法、请求参数、响应结果等。

后续如果做 RepoMind 这样的项目，FastAPI 会更适合作为后端框架。因为 RepoMind 需要提供比较清晰的 API，例如提交 GitHub 仓库地址、获取项目分析报告、生成阅读路线、进行代码问答、生成二次开发方案等。

所以这一阶段我理解到：Flask / FastAPI 的核心作用，就是把 Python 能力封装成可以被外部访问的接口。

2. 请求参数、JSON、路由、Postman

后端接口开发中，一个很重要的基础是理解请求和响应。

路由可以理解为后端程序的访问入口。比如 /chat、/analyze、/report 这些路径，会和后端中的某个处理函数绑定起来。用户访问不同路径，就会触发不同的后端逻辑。

请求方法表示这次请求想做什么，常见的有：

• GET：获取数据
• POST：提交数据
• PUT：修改数据
• DELETE：删除数据

JSON 是前后端之间最常见的数据传输格式。前端提交给后端的数据通常是 JSON，后端返回给前端的数据也通常是 JSON。

例如用户提交一个问题：

{  
"query": "这个项目的入口文件在哪里？"  
}

后端返回结果：

{  
"code": "success",  
"message": "分析成功",  
"data": {}  
}

Postman 则是用来测试接口的工具。它可以直接向后端发送请求，不需要先写前端页面。通过 Postman，可以检查接口是否能访问、参数是否正确、返回结果是否符合预期。

这一部分让我建立了一个基本认知：后端接口的本质，就是接收请求、读取参数、执行逻辑、返回响应。

3. 请求校验与统一响应格式

当用户请求进入后端之后，不能直接相信用户传来的数据。因为用户可能漏传参数、传错类型，或者传入不符合要求的内容。

所以需要请求校验。

请求校验的作用是：

• 判断必填字段是否存在
• 判断字段类型是否正确
• 判断内容格式是否合法
• 防止错误数据直接进入业务逻辑

例如 RepoMind 中，用户提交 GitHub 仓库地址时，后端就需要判断这个 URL 是否为空、格式是否合理，否则后续克隆仓库、分析项目的逻辑就可能出错。

除了请求校验，还需要统一响应格式。

统一响应格式的目的，是让所有接口返回的数据结构保持一致，方便前端处理，也方便后端维护。

常见格式可以设计成：

{  
"code": "success",  
"message": "操作成功",  
"data": {}  
}

其中：

• code 表示业务状态
• message 表示说明信息
• data 表示真正返回的数据

这样无论接口成功、失败、参数错误，前端都可以按照同一种结构去处理。

这一部分让我理解到：后端不是只要“能返回数据”就可以，还要保证接口输出稳定、统一、可预测。

4. 异常处理与错误状态统一

在后端运行过程中，程序一定会遇到错误。

比如：

• 参数错误
• 资源不存在
• 数据库错误
• 第三方接口调用失败
• 程序内部异常

如果不处理这些异常，程序可能会直接崩掉，或者把很底层的错误信息直接暴露给用户。

所以需要统一异常处理。

统一异常处理的作用是：当程序出错时，不让错误随意抛出，而是统一接住，再按照规定格式返回给前端。

可以理解为：

程序出错
↓
全局异常处理器接住错误
↓
判断错误类型
↓
返回统一格式的错误响应

例如：

{  
"code": "validate_error",  
"message": "参数校验失败",  
"data": {}  
}

或者：

{  
"code": "fail",  
"message": "系统异常",  
"data": {}  
}

在开发环境中，可以把详细错误暴露出来，方便调试；但在生产环境中，不能直接暴露内部错误细节，因为这会影响安全性和用户体验。

这一部分让我理解到：异常处理不是额外功能，而是后端稳定性的基础。

5. 数据库与 ORM

后端应用通常不只是处理一次请求，还需要保存数据。

比如 RepoMind 这样的项目，后续可能需要保存：

• 用户提交过的 GitHub 仓库
• 项目分析结果
• 代码问答历史
• 阅读路线
• Demo 生成记录
• 任务执行状态

这些数据不能只放在内存里，而应该存进数据库。

数据库可以理解为更正规的数据存储系统。相比普通的 txt 或 json 文件，数据库更适合存储结构化数据，也方便查询、修改和管理。

在学习 Flask-SQLAlchemy 时，我理解了 ORM 的概念。

ORM 的作用是：把数据库中的表，映射成 Python 里的类和对象。

可以简单理解为：

• 表 → 类
• 行 → 对象
• 列 → 属性

这样开发时就不需要一直手写 SQL，而是可以用 Python 对象的方式操作数据库。

例如：

创建一个用户对象  
↓  
加入数据库 session  
↓  
提交保存

这一部分让我理解到：数据库负责保存数据，ORM 负责让 Python 更方便地操作数据库。

6. PyTest 接口测试

后端接口写完之后，不能只靠手动点几次 Postman 来判断它是否正确，还需要自动化测试。

PyTest 可以理解为一个自动检查工具。它可以帮我们验证代码和接口是否符合预期。

例如测试一个接口时，可以检查：

• 请求是否能正常到达后端
• HTTP 状态码是否正确
• 返回 JSON 里的业务 code 是否符合预期
• 参数错误时是否能返回校验失败
• 正常参数时是否能返回成功结果

这里我还理解到 HTTP 状态码和业务状态码的区别。

HTTP 200 只表示这次请求被后端正常接收并返回了响应，不代表业务一定成功。

业务是否成功，还要看返回 JSON 里的 code 字段。

例如：

{  
"code": "validate_error",  
"message": "参数错误",  
"data": {}  
}

这种情况 HTTP 层可能是 200，但业务层是失败的。

PyTest 的意义在于，它可以让接口测试变得可重复、可自动化。后续项目变复杂后，每次修改代码，都可以通过测试确认原来的功能有没有被破坏。

对于 RepoMind 这样的项目来说，测试也很重要。比如可以测试：

• GitHub URL 为空时是否返回参数错误
• 仓库分析接口是否能正常返回报告
• 代码问答接口是否能处理用户问题
• 异常情况是否能返回统一错误格式

这个部分反映出，测试不是最后才做的补充，而是保证后端稳定性的关键环节。

对 Agent 项目来说，后端不是简单的辅助部分，而是承载 Agent 能力的工程基础。

LLM 和 Agent 负责提供智能能力，Python 后端则负责把这些能力封装成稳定、可访问、可维护的服务。

Python 后端开发能力，是 Agent 应用真正落地成产品的基础。

四、总结

这次阶段性学习让我建立了两条主线。

第一条是 Agent 应用开发主线：从 LLM、RAG、Agent 的基础认知，到 LangChain / LangGraph 对 Agent 能力和流程的工程化组织。

第二条是 Python 后端开发主线：从接口、请求、响应、校验、异常处理、数据库到测试，理解一个 AI 应用真正落地成服务所需要的工程基础。

这两部分最终会在 RepoMind 这样的项目中汇合：Agent 提供智能能力，后端提供稳定的服务承载，二者结合后，才能形成一个真正可运行、可维护、可扩展的 AI 应用。